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DETAILED ACTION 

Priority 

Receipt is acknowledged of papers submitted under 35 U.S.C. 1 19(a)-(d), which 
papers have been placed of record in the file. 

Claim Objections 
The claims are objected to because of the following informalities: 

• The word "include" should be replaced with -includes-. (Claim, line 1 1 ). 

• The word "substitute" should be changed to -substitutes-. (Claim 1 , line 
11). 

• The word "signalling" (used twice) should be changed to -signaling-. 
(Claim 8, line 8). 

. Appropriate correction is required. 

Claim Rejections - 35 USC §112 
The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact termsas to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

Claims 8 and 9 are rejected under 35 U.S.C. 112, first paragraph, as failing to 
comply with the enablement requirement. The claim(s) contains subject matter that was 
not described in the specification in such a way as to enable one skilled in the art to 
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which it pertains, or with which it is most nearly connected, to make and/or use the 
invention. Claim 8 recites: 

"search means for searching the database for the destination IP address in a 
message from the user terminal; identification means responsive to the search means 
finding an IP address in the database to identify said action definition in the message; 
and signalling [sic] means for signalling [sic] action definition parameters to the financial 
service provider site in dependence on identification of an action definition by the 
identification means and receiving a transaction ID or other data not comprising a 
payment card number therefrom; means for substituting at least a payment card number 
within the parameter or parameters of said action definition with the transaction ID or 
other data; and transmission means for sending the modified message to the vendor 
site." 

The specification and drawings do not provide sufficient support so that one of 
ordinary skill in the art could make or use the "search means," "identification means," 
"signalling [sic] means," and "means for substitution." 

Claim Rejections - 35USC§102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 
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Claims 1, 2, 5, 8, and 9 are rejected under 35 U.S.C. 102(b) as being anticipated 
by US Patent No. 5,815,665 to Teper et al. (hereafter Teper). 

In regard to claim 1 , Teper discloses a system and method for conducting 
transactions over the Internet, said system comprising: 

an internet connectivity provider site (see col. 7, lines 40-44); 
a financial service provider site 60 (see FIG. 1) for producing transaction 
identifications ("session ID" - see col. 1 1 . lines 27-28); 

a user terminal 40 (see FIG. 1) programmed with a web browser program and 
connectable to the Internet connectivity provider site for accessing the Internet; and 

a world wide web vendor site 50 (see FIG. 1) configured for sending a payment 
card information entry form 88' (see FIG. 3) having an action definition, having at least 
one parameter, associated therewith, wherein the Internet connectivity provider site is 
configured to intercept messages from the user terminal, which includes said action 
definition and substitutes at least a payment card number within the parameter or 
parameters of said action definition with a transaction ID produced by the financial 
service provider site. Teper recites: "[U]sers provide various account information to the 
Online Broker, such as payment information (e.g., credit card number), name, address 
and phone number. This information is maintained in a brokering database at the 
Online Broker site, and is not exposed to the Service Providers ... In operation, when 
a user connects to a registered SP site and attempts to access an online service, the 
SP site initiates a challenge-response authentication sequence which allows the Online 
Brokering Service to authenticate the user for the SP site. In the preferred 
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embodiment, the SP site sends a challenge message to the user's computer over the 
distributed network (e.g., the Internet), and the user computer responds by generating 
and returning a cryptographic response message . . . Upon determining that a user is 
authentic, the Online Brokering Service preferably sends an anonymous session ID to 
the SP site to allow the SP site to anonymously bill the user for services subsequently 
purchased. As the user purchases online services (such as software downloads, 
accesses to online publications, etc.), the SP site sends billing events to the Online 
Brokering Service, with each billing event specifying both the anonymous session ID 
and a charge to be applied to the user's account." (See col. 2, line 57 - col. 3, line 45). 

In regard to claim 2, Teper further discloses said system employing hypertext 
transfer protocol (HTTP) (see col. 1 1 , lines 34-45). It is inherent within HTTP that all 
messages transferred between the user computer 40, service provider site 50, and 
online broker site 60 would be published in HTML form. It is further inherent that said 
messages would each include a unique Uniform Resource Locator (URL) to identify 
messages sent between the user, service provider, and broker, wherein said URLs 
would be published in HTML, corresponding to the HTTP. (See also col. 9, lines 38- 
49). 

In regard to claim 5, Teper further discloses said vendor (SP) sites as capable of 
recognizing an un-substituted parameter (i.e. credit card number).' and recording a 
transaction in a first manner (see col. 1 , lines 54-65 - Teper discloses the prior art 
method of a user transmitting payment (i.e. credit card) information directly to a service 
provider site). Teper further discloses said sites as configured to recognize substituted 
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parameters (i.e. session IDs) that identify a transaction in a second manner (see col. 
11, lines 27-28). 

In regard to claim 8, Teper further discloses at least one database 64 of vendor 
sites (see col. 8, lines 54-62), some means for searching and identifying said-vendor 
sites within said database (see col. 9, lines 38-49), some means for signaling a vendor 
site, and providing in dependence thereon a substituted parameter transaction ID in a 
message to the vendor site (see col. 9, lines 50-60). 

In regard to claim 9, Teper further discloses said transmission means as 
configured to mimic the user terminal when sending said modified message (see id.). 

Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 3 and 4 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Teper, as applied to claim 1 above, alone. 

In regard to claims 3 and 4, Teper discloses the system and method as set forth 
above, and further discloses said user terminal 40 including an input means and a 
modem means (see col. 8, lines 1-6). Teper does not explicitly disclose modem control 
data that is not modifiable by means of data input using the user input means alone 
(claim 3) and read-only storage means storing a machine specific ID (claim 4). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to use a computer having modem control data that is not modifiable by means 
of data input using the user input means alone, and read-only storage means storing a 
machine specific ID, to implement the three party Internet-based transaction system as 
disclosed by Teper. The modem control data and storage means were well known at 
the time of the invention as options for a personal computer user's system, and would 
be obvious and successful for implementing the internet-based system of Teper. 

Claims 6 and 7 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Teper, as applied to claims 1 and 5 above, and further in view of US Patent No. 
5,692,132 to Hogan (hereafter Hogan). 

In regard to claims 6 and 7, Teper discloses the system and method as set forth 
above, including substituting parameters (i.e. account numbers) with transaction IDs to 
complete a transaction, but does not explicitly disclose said system as capable of 
recognizing an indication of a reason for non-completion of the transaction and sending 
a page to the user terminal in dependence thereon (claim 6), wherein said reason is 
insufficient credit or incorrectly entered payment card related data (claim 7). Hogan 
discloses a system and method for conducting transactions over a computer network, 
wherein a user computer 100 purchases goods from a merchant site hosted on a 
merchant computer 300, through a financial services provider (FSP) site that maintains 
a user's account information (see FIG. 1). Hogan further discloses said system as 
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configured to send a page to a user terminal indicating a reason for non-completion of a 
transaction, wherein said reason is insufficient funds. Hogan recites: 

"If computer 100 detects, in step 51 1 , that the user chose the purchase option, 
computer 100, in step 552, analyzes whether the purchase price subtracted from the 
balance stored in memory 101 results in a negative number. If, in step 552, the resulting 
balance is a negative number (indicating that the price of the item is greater than the 
account balance stored in computer 100), a message is displayed, in step 570, 
informing the user that his account balance is insufficient to purchase the product and 
that he must request a reload to continue." (See col. 9, lines 26-39) (See also FIG. 5B). 

The Teper and Hogan references are analogous art because they are in the 
same field of endeavor— internet-based transactions involving third party services for 
facilitating the transaction. It would have been obvious to one of ordinary skill in the art 
at the time of the invention to provide the means for indicating the insufficiency of an 
account, as disclosed by Hogan, to the system disclosed by Teper. Teper discloses a 
novel system for conducting anonymous transactions over the Internet, but does not 
explicitly address the situation where a user lacks funds to purchase a quantity of 
goods. Hogan provides an obvious and successful solution to this problem by sending a 
message to a user when his funds are insufficient. The motivation for providing the 
indication means would be that as set forth by Hogan— to allow a user of the Teper 
system to stay apprised of his account balance, and chose to reload the account if it 
reaches a low amount. 
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Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure: 

• US Patent No. 6,944,669 to Saccocio 

• US Patent No. 6,938,022 to Singhal 

• US Patent No. 6,725,222 to Musgrove et al. 

• US Patent No. 6,714,933 to Musgrove et al. 

• US Patent No. 6,697,865 to Howard et al. 
. US Patent No. 5,884,272 to Walker et al.\ 

• Cox et al., "NetBill Security and Transaction Protocol," USENIX Workshop 
on Electronic Commerce, New York, NY, 1 995. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jared W. Newton whose telephone number is (571) 
272-2952. The examiner can normally be reached on M-F 8-5. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Richard Chilcot can be reached on (571) 272-6777. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 




May 4, 2007 
JWN 




Notice of References Cited 


Application/Control No. 
10/018,002 


Applicant(s)/Patent Under 

Reexamination 

PHILLIPS, JOHN QUENTIN 


Examiner 
Jared W. Newton 


Art Unit 
3692 


Page 1 of 1 



U.S. PATENT DOCUMENTS 



* 




Country Coda-Number-Kind Code 


Date 
MM-YYYY 


Name 


Classification 


* 


A 


US-5.692.132A 


11-1997 


Hogan, Edward J. 


/ ^p^x 


705/27 


★ 


B 


US-5.815.665A 


09-1998 


Teperetal. / 


% 


709/229 


* 


C 


US-5,884,272 A 


03-1999 


Walker et al. / 




705/1 




D 


US-6.697,865 B1 


02-2004 


Howard etal. \^ 




709/229 


* 


E 


US-6,714,933 B2 


03-2004 


Musgroveetal. ^ 




707/10 




F 


US-6,725,222 B1 


04-2004 


Musgrove et al. 




707/10 




G 


US-6,938,022 B1 


08-2005 


Singhal, Tara C. 


705/74 


* 


H 


US-6,944,669 B1 


09-2005 


Saccoclo, Damian M. 


709/229 




I 


US- 










J 


US- 










K 


us- 










L 


us- 










M 


us- 












FOREIGN PATENT DOCUMENTS 


* 




Document Number 
Country Code- Number-Kind Code 


Date 
MM-YYYY 


Country 


Name 


Classification 




N 














0 














P 














Q 














R 














S 














T 
















NON-PATENT DOCUMENTS 


* 




Include as applicable: Author, Title Date, Publisher, Edition or Volume, Pertinent Pages) 




U 


Cox et al., M NetBi»l Security and Transaction Protocol," USENIX Workshop on Electronic Commerce, New York, NY, 1995. 




V 






W 






X 





•A copy of this reference is not being furnished with this Office action. (See MPEP § 707.05(a).) 
Oates in MM-YYYY format are publication dates. Classifications may be US or foreign. 



U.S. Patent and Trademark Office 

PTO-892 (Rev. 01-2001) 



Notice of References Cited 



Part of Paper No. 20070504 



The following paper was originally published in the 
Proceedings of the First USENIX Workshop on Electronic Commerce 
New York, New York, July 1995. 



NetBill Security and Transaction Protocol 



Benjamin Cox, J. D. Tygar, and Marvin Sirbu 
Carnegie Mellon University 
Pittsburgh, PA 



* 



For more information about USENIX Association contact: 

1. Phone: 510 528-8649 

2. FAX: 510 548-5738 

3. Email: office@usenix.org 

4. WWW URL: http://www.usenix.org 



NetBill Security and Transaction Protocol 

Benjamin Cox J. D. Tygar Marvin Sirbu 

thoth+@cmu.edu tygar@cmu.edu sirbu+@cmu.edu 

Carnegie Mellon University 
Pittsburgh, PA 15213-3890 



Abstract 

NetBill is a system for micropayments for information 
goods on the Internet. This paper presents the NetBill 
protocol and describes its security and transactional 
features. Among our key innovations are: 

• An atomic certified delivery method so that a cus- 
tomer pays if and only if she receives her informa- 
tion goods intact. 

• Outsourcing access control: different users can use 
different access control servers. 

• • A credential mechanism allowing users to prove 
membership in groups. This supports discounts. 

• A structure for constructing pseudonyms to protect 
the identities of consumers. 

1. Introduction and Overview 

Buyers and sellers increasingly want to use the Internet 
to conduct their business electronically. As a base for 
commerce, the Internet poses special challenges due to 
its lack of standard security mechanisms. At the same 
time, the ease with which buyers can peruse catalogs 
published via the World Wide Web makes the Internet 
attractive for commerce. Consumers will want to use the 
Internet as a means for multiple phases of the purchase 
process: searching for suppliers, price negotiation, 
ordering, and payment for goods. In the case of 
information items, such as software or journal pages, the 
Internet can deliver the items. 

Using the Internet for commerce poses new 
variations on traditional issues. Transactions occur in 
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cyberspace with no easily identifiable place of business 
for the merchant or physical delivery site for the 
customer. Transactions are subject to observation by 
third parties sharing the network. And the use of 
computers to support transactions makes record keeping 
easier, exacerbating privacy problems arising from 
transaction data collection by merchants. 

Supporting transactions in cyberspace requires 
electronic analogs for many familiar procedures from 
face-to-face transactions. Parties need to know with 
whom they are dealing, or at least verily their 
creditworthiness. They need to be able to negotiate 
prices, perhaps providing credentials entitling them to 
special discounts, such as a student ID. Parents need 
methods to control where their children shop in 
cyberspace. In the case of information goods, the value 
of an item may be as low as a few cents, requiring 
transaction mechanisms which impose per-transaction 
overheads much smaller than those for typical check 
and credit card purchases. Merchants need to restrict the 
class of customers they support based on their 
credentials, to restrict distribution of sensitive materials. 

We are building a system called NetBill which is 
optimized for the selling and delivery of low-priced 
network goods. A customer, represented by a client 
computer, wishes to buy information from a merchant's 
server. An account server (the NetBill server), maintains 
accounts for both customers and merchants, linked to 
conventional financial institutions. A NetBill transaction 
transfers information goods from merchant to customer, 
debiting the customer's NetBill account and crediting 
the merchant's account for the value of the goods. When 
necessary, funds in a customer's NetBill account can be 
replenished from a bank or credit card; similarly, funds 
in a merchant's NetBill account are made available by 
depositing them in the merchant's bank account. NetBill 
acts as ah aggregator to combine many small 
transactions into larger conventional transactions, 
amortizing conventional overhead fees. 

The transfer of an information good consists of 
delivering bits to the customer. Users may be charged on 
a per item basis, by a subscription allowing unlimited 
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cyberspace with no easily identifiable place of business 
for the merchant or physical delivery site for the 
customer. Transactions are subject- to observation by 
third parties sharing the network. And the use of 
computers to support transactions makes record keeping 
easier, exacerbating privacy problems arising from 
transaction data collection by merchants. 

Supporting transactions in cyberspace requires 
electronic analogs for many familiar procedures from 
face-to-face transactions. Parties need to know with 
whom they are dealing, or at least verify their 
creditworthiness. They need to be able to negotiate 
prices, perhaps providing credentials entitling them to 
special discounts, such as a student ID. Parents need 
methods to control where their children shop in 
cyberspace. In the case of information goods, the value 
of an item may be as low as a few cents, requiring 
transaction mechanisms which impose per-transaction 
overheads much smaller than those for typical check 
and credit card purchases. Merchants need to restrict the 
class of customers they support based on their 
credentials, to restrict distribution of sensitive materials. 

We are building a system called NetBill which is- 
optimized for the selling and delivery of low-priced 
network goods. A customer, represented by a client 
computer, wishes to buy information from a merchant's 
server. An account server (the NetBill server), maintains 
accounts for both customers and merchants, linked to 
conventional financial institutions. A NetBill transaction 
transfers information goods from merchant to customer, 
debiting the customer's NetBill account and crediting 
the merchant's account for the value of the goods. When 
necessary, funds in a customer's NetBill account can be 
replenished from a bank or credit card; similarly, funds 
in a merchant's NetBill account are made available by 
depositing them in the merchant's bank account. NetBill 
acts as an aggregator to combine many small 
transactions into larger conventional transactions, 
amortizing conventional overhead fees. 

The transfer of an information good consists of 
delivering bits to the customer. Users may be charged on 
a per item basis, by a subscription allowing unlimited 



access, or by a number of other pricing models, A more 
detailed examination of the NetBill model may be found 
in [10]. 

NetBill requires an efficient set of protocols to 
support price negotiation, goods delivery and payment. 
This paper outlines our protocols. 

Among our key innovations are: 

• A method of (atomic) certified delivery so that a 
customer pays if and only if she receives her infor- 
mation goods intact. 

• A system for allowing access control to be out- 
sourced — so that different users may use different 
access control servers. (For example, some chil- 
dren's accesses may be governed by a PTA access 
control server, while other children may be under 
the domain of access control servers set up by a 
church group.) 

• A credential mechanism for allowing users to easily 
prove membership in groups, to qualify for dis- 
counts or for other purposes. 

• A structure for easily constructing pseudonyms so 
that buyers of information can protect their identi- 
ties. 

2. The NetBill Transaction Model 

The NetBill transaction model involves three parties: 
the customer, the merchant and the NetBill transaction 
server. A transaction involves three phases: price 
negotiation, goods delivery, and payment. For 
information goods which can be delivered over the 
network, the NetBill protocol links goods delivery and 
payment into a single atomic transaction. 

In a NetBill transaction, the customer and merchant 
interact with each other in the first two phases; the 
NetBill server is not involved until the payment phase, 
when the merchant submits a transaction request. The 
customer contacts the NetBill server directly only in the 
case of communications failure or when requesting 
administrative functions. Figure I shows the 
relationships among parties in a NetBill transaction. 

2.1. Transaction Objectives 

For a NetBill transaction, we have the following set of 
objectives. (Similar versions of objectives (a)-{d) below 
can be found in [2].) 

a) Only authorized customers can charge against a 
NetBill account. 

b) The customer and merchant must agree on the item 
to be purchased and the price to be charged. 
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Figure 1: Parties in a NetBill Transaction. 

c) A customer can optionally protect her identity from 
merchants. 

d) Customers and merchants are provided with proof 
of transaction results from NetBill. 

In addition, we have the following objectives to support 
price negotiation and goods delivery. 

e) There is an offer and acceptance negotiation phase 
between customer and merchant. 

f) A customer may present credentials identifying her 
as entitled to special pricing or treatment. 

g) A customer receives the information goods she pur- 
chases if and only if she is charged (and thus the 
merchant is paid) for the goods. 

h) A customer may need approval from a fourth 
(access control) party before the NetBill server will 
allow a transaction. 

Finally, we add as a general objective for all phases of 
the purchase process: 

i) The privacy and integrity of communications is 
protected from observation or alteration by external 
parties. 

To achieve these goals, the NetBill protocol provides for 
strong authentication and privacy, atomic payment and 
delivery protocols, and a flexible access control system. 

In the price negotiation phase, the customer 
presents evidence of her identity, and (optionally) 
supplemental credentials, and requests a price quote on 
an item. The customer may also include a bid for the 
item. The merchant responds with a price offer. 



In the second phase, the customer accepts or 
declines the offer. In the case of information goods, 
acceptance constitutes an order for network delivery. 
The merchant provisionally delivers the goods, under 
encryption, but withholds the key. 

Key delivery is linked to completion of the third 
phase, the payment protocol. In this phase, the customer 
constructs, and digitally signs, an electronic payment 
order (or EPO) and sends it to the merchant. The 
merchant appends the key to the EPO and endorses 
(digitally signs) the EPO, forwarding it to the NetBill 
server. The NetBill server returns a digitally signed 
receipt, which includes the key, to the merchant, who 
forwards a copy to the customer. 

3. The Transaction Protocol 

We use the notation "X => Y" to indicate that X sends 
the specified message to Y The basic protocol consists 
of eight steps, which are: 

1 . C => M Price request 

2. M C Price quote 

3. C => M Goods request 

4. M => C Goods, encrypted with a key K 

5. C M Signed Electronic Payment Order 

6. M=>N Endorsed EPO (including K) 

7. n => M Signed result (including K) 

8. M => C Signed result (including K) 

Objective (a) from Section 2.1 is realized because 
the customer must be authenticated to NetBill before the 
EPO (generated in step 5) will be accepted (in step 6). 

Objective (b) is achieved because the relevant 
information is included in the EPO which must be 
signed by the customer in step 5 and endorsed by the 
merchant in step 6. 

Section 4.2 presents a mechanism implementing 
objective (c). 

Objective (d) is realized through the digitally 
signed receipt from NetBill in step 7. 

Objective (e) is achieved by the exchange in steps 1 
and 2 of the protocol. 

Section 5.1 presents a solution implementing 
objective (f). 

Objective (g) is realized by the exchange in steps 4- 
8, which we call certified delivery. The customer first 
gets a version of the goods encrypted with a key K. The 



goods are also cryptographically checksummed. In this 
way, the customer uses the checksum to confirm that she 
received the goods without transmission error. The 
customer returns the checksum to the merchant together 
with other information, and that message is forwarded to 
the NetBill server. The key K that is needed to decrypt 
the goods is registered with the NetBill server and also 
sent to. the customer (step 8). The exchange in steps 4-8 
provides protection to the customer against fraud by the 
merchant. For example, suppose there is a discrepancy 
between what the customer ordered and what the 
merchant delivered. The customer can easily 
demonstrate the discrepancy to a third party (such as a 
judge). The customer has NetBilFs receipt (step 7, 
forwarded in step 8) indicating what was ordered, the 
amount charged and the key K reported to NetBill by the 
merchant. The customer also has registered with NetBill 
the checksum of the encrypted goods. Thus if the goods 
are faulty (e.g., purchased software doesn't run), it is 
easy to demonstrate that the problem lies with the goods 
as sent and not with any subsequent alteration. This 
certified delivery technique also protects the merchant 
by requiring the customer to pay and the payment to 
clear through the NetBill server before the customer 
gets the use of the goods. (A more general discussion of 
the role of certified delivery and atomicity in general for 
electronic commerce can be found in [13].) 

Section 5.2 presents a solution for objective (h). 
Objective (i) is realized by encrypting 
communications between all pairs of parties and 
providing integrity checks on those messages. 

3.1. Notation 

We use the following notation to denote cryptographic 
operations. X and Y always represent communicating 
parties. K always represents a cipher key. The protocol 
is a sequence of messages exchanged among three 
parties: C, the customer; A/, the merchant; and N> the 
NetBill server. 

T X y(Identity) A Kerberos ticket proving to / 
that A' is named by Identity, and 
establishing a session key XY 
shared between them. 

CC(Message) A cryptographic checksum of 
Message, using an algorithm 
such as the Secure Hash Algo- 
rithm (SHA) hash function pre- 
sented in [5]. 



E K (Message) 



Exw&Message) 
[Message]\ 



Message, encrypted by a sym- 
metric cipher Using key K. The 
key K may be denoted as XY, 
meaning that it is known only to 
parties and Y. The encrypted 
message implicitly includes a 
nonce. 

Message, encrypted in party X*s 
public key using the RSA cryp- 
tosystem as presented in [8]. 

Message, encrypted in party 
Ts private key using RSA. 

Message, clearsigned by X 
using RSA public key cryptog- 
raphy. Clearsigning is imple- 
mented by forming Message, 
Timeslamp, Ex.pRi(CC(A/&y- 
sage, Timestamp)). This is com- 
putationally efficient and allows 
any party to read the Message 
text without needing X*s public 
key. The clearsigned item 
implicitly includes a nonce. 

Message, signed and times- 
tamped by fusing the Digital 
Signature Algorithm (DSA) as 
described in [6]. 

Message, encrypted for fusing 
RSA public key cryptography. 
For computational efficiency, 
this is implemented by forming 
E K {Message), E x . PUB (/0» The 
encrypted message implicitly 
includes a nonce. 



3.2. The Price Request Phase 

This section assumes possession of tickets; the method 
for obtaining tickets is shown in Section 4. The Identify 
item may actually be a pseudonym, as shown in Section 
4.2. 



!. C=»M T CM (Identity),E CM (Credentia!s, 
PRD, Bid, RequestFlags, TID) 

2, M C E CM (ProductlD, Price, Request- 
Flags, TID) 



[Message] x . DSA 
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These two steps represent a request/response 
message pair in which the customer requests a price 
quote of the merchant. The customer presents an 
identifying ticket (the identity presented may be a 
pseudonym; see Section 4.2 for details on pseudonyms) 
to the merchant, along with some optional credentials 
establishing her membership in groups which may make 
her eligible for a discount. (We discuss these credentials 
in Section 5.1.) 

The customer passes parameters indicating Product 
Request Data {PRD, an arbitrary stream of application- 
specific data which the customer and merchant use to 
specify the goods) and some flags. These RequestFlags 
are the customer's indication of her request for the 
disposition of the transaction (i.e., delivery instructions; 
see Section 3.6 for different transaction options). 

The customer may also optionally include a Bid, 
indicating to the merchant a price she may be willing to 
pay for the item. 

The Transaction ID, TID, is optional in step 1 . Steps 
I and 2 may be repeated as needed until the customer 
and merchant can agree on a price; the TID is present to 
indicate to the merchant that this is a repeated request. 

The merchant stores the PRD for later use in 
delivering the goods, generates a new set of 
RequestFlags based on its response to the customer's 
RequestFlags, and generates a price quote and a TID (if 
one was not supplied in step 1) to identify this 
transaction in later steps. The TID is not globally - 
unique; it is used only by the customer and merchant to 
maintain context between them. 

The ProductID returned by the merchant in step 2 is 
a human-readable product description that will appear 
on the customer's NetBill statement. 

3.3. The Goods Delivery Phase 

Once the customer and merchant have negotiated a price 
for the goods in question, the customer directs the 
merchant to deliver the goods by supplying the TID that 
was used in the price request phase: 

3. C => M T CM (Identity), E CM (TJD) 

4. M => C E K (Goods), 

E C M(CC(E K (Goods)), EPOID) 

The merchant generates a unique symmetric cipher 
key K, encrypts the goods using this key and sends the 
encrypted goods to the customer, along with a 
cryptographic checksum computed on the encrypted 
goods, so that the customer will immediately detect any 
discrepancy before proceeding. The merchant also sends 



an Electronic Payment Order ID, or EPOID, with the 
goods. 

The EPOID is a globally unique identifier which 
will be used in the NetBill server's database to uniquely 
identify this transaction. It consists of three fields: a field 
identifying the merchant, a timestamp marking the time 
at the end of goods delivery, and a serial number to 
guarantee uniqueness. 

The specification that the EPOID must be globally 
unique is used to prevent replay attacks, in which 
unscrupulous merchants reuse customers' old signed 
payment instructions. The timestamp portion of the 
EPOID is used to expire stale transactions; it must be 
generated at the end of goods delivery because the 
delivery (especially for very large goods) may take 
longer than the payment expiration time. 

Because the goods are delivered encrypted in step 
4, the customer cannot use them. The key K needed to 
decrypt the goods will be delivered in the payment 
phase, which follows. 

3.4. The Payment Phase 

After the encrypted goods are delivered, the customer 
submits payment to the merchant in the form of a signed 
Electronic Payment Order, or EPO. At any time before 
the signed EPO is submitted, a customer may abort the 
transaction and be in no danger of its being completed 
against her will. The submission of the signed EPO 
marks the "point of no return" for the customer. 

An EPO consists of two sections, a clear part 
containing transaction information which is readable by 
the merchant and the NetBill server, and an encrypted 
part containing payment instructions which is readable 
only by the NetBill server. The clear part of the EPO 
includes: 

• The customer's (possibly pseudonymous) identity 

• The human-readable Product ID (from step 2) 

• The negotiated price (from step 2) 

• The merchant's identity 

• The cryptographic checksum of the encrypted 
goods, to forestall debate over the content of the 
goods or whether they were received completely 
and correctly 

• The cryptographic checksum of the Product 
Request Data (from step 1), to forestall debate over 
the details of the order 

• The cryptographic checksum of the customer's 
account number with an account verification nonce, 
so that the merchant may verify that any supplied 
credentials (see Section 5.1) were used correctly 



• The globally-unique EPOID 

The encrypted part of the EPO includes: 

• A ticket proving the customer's true identity 

• Any required authorization tokens (see Section 5.2) 

• The customer's NetBill account number 

• The account verification nonce 

• A customer memo field 

The EPO is a tuple: 

Identity, 
ProductID, 
Price, 
M, 

CC(E K (Goods)), 
CC(PRD), 

CC(CAcct, AcctVN), 
EPOID, 

Tcw(Trueldentity), 

EchKAtathorization, 
CAcct, 
AcctVN, 
CMemo) 

Henceforth, we use the terminology EPO to denote 
this tuple. 

After the customer presents the signed EPO to the 
merchant, the merchant endorses it and forwards the 
endorsed EPO to the NetBill server. The endorsed EPO 
adds the merchant's account number, the merchant's 
memo field, and the goods decryption key, as well as the 
merchant's signature: 

[[EPO] c , MAcct, MMemo, K] M 

At any time before the endorsed EPO is submitted 
to the NetBill server, the merchant may abort the 
transaction and be in no danger of its being completed 
against his will. The submission of the endorsed EPO 
marks the "point of no return" for the merchant. 

The phase containing the submission and 
endorsement of the EPO is denoted: 

5. C => M T CM (ldentity), E CM ([EPO] c ) 

6. M N T MN (M), E MN ([[EPO) c , MAcct, 

MMemo, K] M ) 

Upon receipt of the signed and endorsed EPO, the 
NetBill server makes a decision about the transaction 
and returns the result to the merchant, who in turn 
forwards it to the customer. 



The NetBill server makes its decision based' on 
verification of the signatures, the privileges of the users 
involved, the customer's account balance, and the 
uniqueness and freshness of the EPOID. It then issues a 
receipt containing the result code, the identities of the 
parties, the price and description of the goods, the 
EP01D, and the key K needed to decrypt the goods. The 
receipt is digitally signed by the NetBill server, using 
the Digital Signature Algorithm (DSA). The receipt is 
denoted: 

Result, Identity, Price, ProductID, M, K, EPOID 

For this step, DSA is used rather than RSA because 
of its relative performance. While RSA signatures may 
be verified quickly, they are time-consuming to create; 
DSA signatures, on the other hand, may be created 
quickly. By using RSA for customer and merchant 
signatures and DSA for NetBill signatures, we may shift 
some computing load away from the NetBill server. 

Some of the resulting burden on the merchant can 
be lifted by recognizing that, from a business risk 
perspective, it may be sufficient for a merchant to verify 
only a random sample of receipts signed by the NetBill 
server. Since integrity and authenticity are assured by 
the symmetric key encryption protocol, only 
accountability is at stake. 

This receipt is returned to the merchant, along with 
an indication of the customer's new account balance 
(encrypted so that only she may read it). The EPO ID is 
repeated in the customer-specific data to ensure that the 
merchant cannot replay data from an earlier transaction. 

7. n M E MN ([Receipt] N . DSA , 

E CN (EP01D, CAcct, Bal, Flags)) 

The Flags included in the customer-specific data 
indicate simple messages from the NetBill server to the 
customer; for example, that the account balance has 
reached a "low-water mark" and should be replenished 
soon. 

8. M => C E CM ([Receipt] N . DSAf . 

E CN (EPO!D, CAcct, Bal, Flags)) 

In step 8, the merchant responds to the request from 
the customer in step 5, forwarding the messages 
returned by the NetBill server in step 7. 

3.5. Status Query Exchange 

In the event of communications failure after step 5 of 
the protocol, the customer or merchant may be unaware 
of the transaction's status. (Before step 5, the transaction 



may be aborted with no difficulty, as no parties have yet 
signaled their commitment.) The system supports a 
status query exchange for delivery of this information. 

The request, and response proceed as one of the 
following exchanges, assuming the information is 
available. In each case, an alternate response is possible, 
indicating that the queried party does not have the 
requested information (possibly indicating why). 

• The merchant requests the transaction status from 
the NetBill server: 

1. M => N T MN (M), E MN (EPOID) 

2. N => M E MN ([Receipt] N . DSA , 

E CN (EPOID, CAcct, Bal, Flags)) 

• The customer requests the transaction status from 
the merchant: 

1 . C => M T CM (Identity), E CM (EP01D) 

2, M => C E CM ([Receipt] N . DSA , 

E CN (EP01D, CAcct, Bal, Flags)) 

• The customer requests the transaction status from 
the NetBill server: 

1. C => N T CN (TrueIdentity), E CN (EPO!D) 

2. N => C E CN ([Receipt] N . DSA , 

EPOID, CAcct, Bal, Flags) 

• The customer requests the transaction status from 
the merchant for a Non-NetBill transaction (see 
Section 3.6): 

1 . C => M T CM (Identity), E CM (EPOID) 

2. M C E CM (Result, K) 

3.6. Handling Zero-Priced Goods 

We anticipate that many NetBill transactions will be for 
subscription goods; i.e., goods for which the customer's 
marginal price is zero. With zero-priced goods, fraud is 
less important, and so we make several refinements to 
make our protocol more efficient in these cases. 

First, we include a flag in the RequestFlags field of 
the price request (step 1) informing the merchant "If the 
price for this product is zero, treat this message- as an 
automatic request for the goods." 



Zero-priced transactions do not need to go through 
the NctBill server, as long as both parties agree. We can 
put another flag in the RequestFlags that informs the 
merchant i€ l require a NetBill receipt for this 
transaction." If this flag is present, the merchant must 
submit the transaction to the NetBill server, even if the 
price is zero. (The merchant may also decide to submit a 
zero-price transaction to the NetBill server.) 

A customer or merchant may want to use the 
NetBill server on a zero-priced transaction if they 
require a signed receipt from a third party confirming 
the transaction. While subscription goods may not 
require a receipt, a merchant may decide to put a zero- 
priced purchase through NetBill in a "buy ten, get one 
free" situation so as to be able to prove that he actually 
provided the free item. 

The merchant may. change his price quote 
depending on this flag; if NetBill charges the merchant 
for billing services, the merchant may want to recover 
this cost if the customer requests a NetBill receipt for 
what might otherwise be a zero-priced transaction. ' 

Combinations of these flags allow us to support 
four basic types of zero-price delivery: 

3.6J. Type I: Zero-Price Certified Delivery 

This protocol eliminates the separate product request 
phase. Because steps 2 and 4 from the original protocol 
are combined, we indicate that by making steps 2 and 4 
into a single step labeled 2/4. 

1. C => M T CM (ldentity), E CM (Credentials, 
PRD, Bid, RequestFlags, TID) 

2/4. M => C E CM (ProductID, Price(=0), 

RequestFlags, TID), E K (Goods), 
E C M(CC(E K (Goods)), EPOID) 

5. C => M T CM (Identity), E CM ([EPO] c ) 

6. M=>N T MN (M), E MN ([[EP0] o MAcct, 

MMemo, K] M ) 

7. N => M E MN ([Receipt] N . DSA , 

E CN (EP01D, CAcct, Bal, Flags)) 

8. M => C . E C M([Receipt] N _ DSA , 

E CN (EP01D, CAcct, Bal, Flags)) 

3.6.2. Type II: Certified Delivery without 
NctBill Server 

This protocol improves on Type 1 by further eliminating 
the call to the NetBill server. With this modification, the 



payment phase becomes little more than an 
acknowledgment. 

I. C^M T CM (Identity), E CM (Credentials, 
PRD, Bid, RequestFlags, TID) 

2/4. M => C E CM (Pr6ductID, Price(=0), 

RequestFlags, TID), E K (Goods), 
ECM(CC(E K (Goods)), EPOID) 

5. C => M T CM (Identity), E CM (EPOID, 
CC(E K (Goods))) 

8. M C E CM (Result, K) 

3.6.3. Type III: Verified Delivery 

This protocol is nearly the same as the Type 11 protocol, 
except that the goods are encrypted in the shared session 
key CM. This bypasses the certified delivery 
mechanism, allowing the customer's software to begin 
streaming the goods to a viewer rather than being 
obliged to wait until all the goods have been delivered 
before receiving the key. 

1 . C => M T CM (Identity), E CM (Credentials, 
PRD, Bid, RequestFlags, TID) 

2/4. M => C E CM (ProductlD, Price(=0), 
RequestFlags, TID, Goods, 
CC(Goods), EPOID) 

5. C => M T CM (ldentity), E CM (EPOID, 
CC(Goods)) 

8. M => C E CM (Result) 

3.6.4. Type IV: Unverified Dielivery 

This protocol improves on Type III by eliminating the 
acknowledgment of goods delivery in the payment 
phase if the merchant does not need it. 



1. 



M T CM (Identity), E CM (Credentials, 
PRD, Bid, RequestFlags, TID) 



2/4. M => C E CM (ProductID, Price(=0), 
RequestFlags, TID, Goods, 
CC(Goods)) 

4. Identities and Authentication 

When a customer creates a NetBill account, she receives 
a unique User ID and generates the RSA public key pair 



associated with that User ID. This key pair is certified 
by NetBill, and is used for signatures and authentication 
within the system. (See [4] for a discussion of public 
key certification.) 

Section 3.4 showed how these signatures will be 
used in the payment phase of the protocol. However, our 
protocol also uses Kerberos tickets. The NetBill 
transaction protocol involves several phases, for price 
negotiation, goods delivery, and payment; only the last 
of these phases requires nonrepudiable signatures. 
Instead of using public key cryptography for message 
authentication and encryption throughout the NetBill 
system, we use symmetric cryptography because it 
offers significant performance advantages. 

We use the public key cryptography infrastructure 
to alleviate problems with traditional symmetric-key 
Kerberos (see [12]): 

Kerberos uses a two-level ticket scheme; to 
authenticate oneself to a Kerberos service, one must 
obtain a service ticket, which establishes a shared 
symmetric session key between the client and server, 
and establishes that the Kerberos Ticket Granting Server 
believes the client's identity. To obtain a service ticket, a 
client must first obtain a ticket-granting ticket (or TGT), 
which proves the client's identity to the Ticket Granting 
Server. A client obtains a TGT via request from a Key 
Distribution Center, or KDC. 

The Kerberos KDC/TGT arrangement introduces 
two significant problems that we may alleviate using 
public key cryptography. First, because it maintains a 
shared symmetric cipher key with every principal in the 
system, it is an attractive target for attack; recovering 
from compromise of the KDC requires establishing new 
shared keys with all users of the system. Second, a KDC 
and TGT will be a communications or processing 
bottleneck if a large number of users present a heavy 
traffic load. 

To eliminate the Ticket Granting Server, we replace 
the TGT with a public key certificate, allowing each 
service to act as its own Ticket Granting Server. That is, 
a user presents a service ticket request encrypted with a 
certified public key (we call this a Public Key-based 
TGT, or PKTGT), and receives in response a symmetric- 
cipher-bascd service ticket. This service ticket is 
identical in form to a Kerberos service ticket. The Key 
Distribution Center is replaced by a key repository. The 
protocol for a customer to obtain a service ticket for a 
merchant M is as follows (before this step occurs, the 
customer requests the merchant's public key certificate 



over any available channel — such as an unsecured 
remote procedure call): 

1. c M [{Identity, M, Timestamp, K} M ] C 

2. M => C E K (T CM (Identity), CM) 

This model preserves the efficiency of symmetric 
ciphers for most communication and repeated 
authentication, and isolates the computational expense 
of public key cryptography to initial authentication 
. between parties. We refer to this model as "Public Key 
Kerberos," or U PK Kerberos." 

In the NetBill system, a customer obtains Kerberos 
tickets for the NetBill transaction server at the 
beginning of a session and obtains Kerberos tickets for 
merchants as she needs them. Merchant servers will 
continually maintain their own tickets for the NetBill 
transaction server. 

4.1. Key Repository 

Private keys are large, so users cannot be expected to 
remember them. Permanently storing private keys at a 
user's workstation poses security risks and restricts the 
user's electronic commerce activities to a single 
workstation. NetBill uses a key repository to optionally 
store customers* private keys. These keys are encrypted 
by a symmetric key derived from a passphrase known 
only to the customer. 

4.1.1. Key Validation and Revocation Cer- 
tificates 

We use a public key certificate scheme (like that 
presented in [4]) to bind User IDs to keys, with NetBill 
as the certifying authority. NetBill generates a certificate 
when a customer first proves her identity and begins 
using NetBill. 

However, allowing merchants, as services, to grant 
their own tickets based on these certificates poses a 
problem: NetBill is no longer involved in ticket- 
granting, and cannot prevent a ticket from being issued 
to a user with a compromised key. NetBill needs to 
invalidate compromised keys as quickly as possible. 

NetBill maintains a Certificate Revocation List 
(CRL) at its server. When a key is compromised, the 
owner creates a Revocation Certificate and places it in 
the key repository along with her key. Any party can 
check that a given key has not been compromised by 
examining the revocation list. 

Initially, it would seem that it is necessary for the 
customer and merchant to contact the server to check 
CRLs on each transaction. However, it is possible to 



eliminate this check by allowing the NetBill transaction 
server to do it when it processes the payment 
transaction. By delaying the CRL check to late in the 
protocol, we introduce some minor risks. Customers and 
merchants may disclose information such as their 
preference for particular items or special prices to bogus 
peers, but there is no financial risk. 

4.2. Pseudonyms 

Some customers want to disguise their identities. 
NetBill provides two pseudonym methods to protect the 
privacy of the customer's identity: a per-transaction 
method that uses a unique pseudonym for each 
transaction, and a per-merchant method that uses a 
unique pseudonym for each customer-merchant pair. 
(See [3] for a full discussion of privacy protection with 
pseudonyms.) The per-merchant pseudonym is useful 
for customers who wish to maintain a consistent 
pseudonymous identity to qualify for frequent-buyer 
discounts. 

These pseudonym schemes are implemented by 
introducing a pseudonym-granting server, P y to create 
pseudonymous PKTGTs for the customer. The protocol 
for obtaining and using a pseudonymous PKTGT is as 
follows. The customer obtains the pseudonymous 
PKTGT in steps 1-2, and uses it with a merchant in 
steps 3-4 exactly as she would use a normal PKTGT: 

1. C P [{Trueldentity, M, Timestamp, Kl, 

Type} p ] c 

2. P => C E K i(K2, [{Pseudonym, M, Times- 

tamp, K2} M ]p> [Trueldentity, M, 
Pseudonym, Timestamp] P ) 

3. C => M [{Pseudonym, M, Timestamp, 

K2} M ] P 

4. M=>C E K2 (T CM (Pseudonym), CM) 

The protocol is the same for both kinds of 
pseudonyms; the desired type of pseudonym (per- 
merchant or per-transaction) is indicated in the Type 
field in step 1. The extra message [Trueldentity, M, 
Pseudonym. Timestamp] P in step 2 is the customer's 
receipt proving that she was using the pseudonym 
Pseudonym with the named merchant at the time 
indicated. This may be useful to the customer in 
conjunction with the receipt received in step 8 of the 
transaction (which contains only the pseudonym) to 
later prove that she was involved in the transaction. 



5. Credentials and Authorizations 

In [7], Neuman presents a system of using restricted 
proxies for authorization. A restricted proxy is a ticket 
giving the bearer authority to perform certain operations 
named in the ticket. NetBill uses a similar construct to 
implement credentials to prove group membership (to 
allow merchants to provide discounts to special groups) 
and to implement access control mechanisms. 

5.1. Credentials for Group Membership 

An organization can provide a credential server which 
issues credential proxies proving membership in a 
group. In this case, the credential server is asserting a 
fact (membership in a group) about which it is 
authoritative. For example, an auto club may provide a 
credential server which issues credentials to the 
members of the club; merchants who offer discounts to 
the club's members will accept these credentials as 
proof of membership. The protocol for obtaining a 
credential (assuming the customer has already obtained 
a service ticket for the credential server) from a 
credential server, G, is as follows: 

1 . C => G T cc (Identity), E CG (Group, CAcct) 

2. G => C E CG ([Group, Detail, Identity, 

CC(CAcct, AcctVN), Times- 
tamp] G , AcctVN) 

Credentials obtained in this manner are presented to 
merchants in the price request phase of the transaction 
protocol, step I . 

A credential issued to a customer may be 
unrestricted, or it may optionally be restricted for use on 
a specific account (for example, in order to prevent 
corporate employees from taking advantage of 
corporate discounts for personal purchases). This is 
accomplished by passing the account number to the 
group server as part of the request. If the account 
number is appropriate for this group, the credential will 
be issued. The credential contains a cryptographic 
checksum of the account number and an "Account 
Verification Nonce," which is also returned to the 
customer along with the credential. 

This nonce is a pseudorandom number ensuring 
that merchants can neither determine which different 
customers (or the same customer in repeated sessions) 
are using the same account nor easily verify guesses of 
the customer's account number. The nonce is passed 
along to the NetBill server in the encrypted part of the 
EPO so that the NetBill server can verify that the 
checksum passed to the merchant (for his comparison to 



the credential) corresponds to the account number 
actually being used. 

The Detail field allows a credential server to 
include additional information in a format specific to the 
credential server. This would allow, for example, a 
multiple-journal subscription credential server to issue a 
single credential for all subscribers, using the Detail 
field to specify which journal subscriptions the customer 
holds. 

Credentials can also be used by cooperating 
merchants to restrict information access. In this way, 
merchants only sell to approved customers: those who 
can present a certain credential. This offers a solution 
for merchants who, for example, can restrict distribution 
of sensitive documents only to individuals whose 
credentials verify a need-to-know. 

5.2. Access Control Mechanism 

As noted in [7], proxies can implement access control. 
An account owner (such as a* parent) may have a 
restriction on the account such that no purchases can be 
completed by a given customer (such as a child) without 
approval from an access control server. This allows 
different organizations to provide access control 
services. For example, both the PTA and a church group 
could offer competing access control services. 

To obtain an access control authorization, a 
customer C must present details of a specific transaction 
to the access control server A y who grants a single-use 
proxy authorizing the given transaction. The protocol is 
as follows: 

1 , C => A T CA (ldentity), E CA (M, ProductlD, 

Price, CC(E K (Goods)), EPOID, 
CAcct) 

2. A => C E CA (E A . PRI (CC(Identity, M, Pro- 

ductlD, Price, CC(E K (Goods), 
EPOID, CAcct))) 

The item returned in step 2 is the Authorization 
item used in step 5 of the transaction protocol (see 
Section 3.4). 

6. Complaints and Failure Analysis 

The NetBill protocols are robust against failures, and 
retain essential information to protect customers and 
merchants against fraud. Our system can respond to 
complaints made by either the customer or the 
merchant. In this section, we examine those complaints 
and discuss how they are handled. First, we look at 



potential customer complaints, and then at potential 
merchant complaints. 

6.1. Customer Complaints 

6.1.1. Incorrect or Damaged Goods 

• "This isn't the product I specified." 

• "The goods arrived broken or incomplete." 

• "The decryption key 1 was given was wrong." 

In the event that the decrypted goods do not match 
the product description as given by the merchant, the 
dispute must be brought to the attention of a human 
arbitrator, who will determine the validity of the 
customer's complaint and, if appropriate, direct the 
merchant to provide a refund. 

The arbitrator uses the registered copies at NetBill 
of the customer's signed EPO containing a 
cryptographic checksum of the encrypted goods, and the 
merchant's signed endorsement indicating his 
agreement with that cryptographic checksum and 
attesting to the decryption key. The arbitrator compares 
these registered values against the copy of the encrypted 
goods and decryption key provided by the customer in 
her complaint. The arbitrator can easily determine 
whether the purported problem with the goods is the 
fault of the merchant or an error by the customer. 

• "The goods are not as advertised." 

The protocol can be used to demonstrate whether 
the goods delivered are the goods ordered, as shown 
above. However, if the customer was induced to buy the 
goods by false advertising claims, this protocol provides 
no help. The customer must lodge a complaint with the 
Federal Trade Commission or other appropriate agency. 
It is important for billing servers to monitor these 
charges and assist with their resolution. 

• "I bought this but never got the decryption key," 

This complaint may be answered by directing the 
customer to perform a status query (see Section 3.5) to 
retrieve the key. in the event that the decryption key 
does not yield a satisfactory decryption, the dispute will 
change to one of the other complaints listed. 

6.1.2. TVansaction Disputes 

• "I agreed to pay $X, but was charged $Y instead." 

• "I've only bought $X worth of goods, but my bal- 
ance has gone down by $Y." 

Because the NetBill server has a signed EPO from 
the customer, it can prove that the customer approved 



the purchase(s) for $Y. In the event that the NetBill 
server cannot provide the signed EPO(s), the customer's 
money is refunded. This protects customers against 
fraud by the operators of the NetBill server. 

• "I never bought this, but it appears on my state- 
ment." 

• "I told the merchant no, but he put it through any- 
way." 

Because the NetBill server has signed EPOs from 
the customer, it can prove that the customer approved 
the purchases. In the event.that the NetBill server cannot 
provide the signed EPOs, the customer's money is 
refunded. 

• "You told me this transaction didn't go through, but 
I got charged anyway." 

Because the NetBill server provides signed receipts 
even for failed transactions, the customer can present 
these receipts to prove that the transactions were 
declined. If the customer cannot produce these receipts 
and the NetBill server claims to have approved the 
transactions, it must provide the decryption keys for the 
information goods (via status query exchange). 

6.2. Merchant Complaints 

6.2.1. Insufficient Payment 

• "I sold $X worth of goods but only received $Y." 

•..."You told me this transaction went through, but I 
never got paid for it." 

In all transactions, the NetBill server provides a 
signed receipt indicating the success or failure of a 
transaction. In the event that a merchant is not properly 
credited, he can prove the error by presenting these 
signed receipts. 

7, Conclusion 

This paper has presented the NetBill protocols. These 
protocols have introduced new methods for certified 
delivery, access control, user certificates, pseudonyms, 
and their integration. These protocols are designed to 
provide very high degrees of security and flexibility 
while still providing good efficiency. However, this 
paper docs not represent final work; it is a snapshot of 
our current design. We plan to test our design in a major 
wide-scale pre-commercial beta test of the NetBill 
system beginning in 1996. 

The NetBill project is committed to open protocols. 
We are eager to work with others to make our protocols 



as widely applicable and interoperable as possible, and 
welcome comments. 

For more information on the current state of the 
NetBill project, we invite readers to consult our WWW 
page at http : / /www. ini . emu . edu/netbill/. 
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